IBIS Macromodel Task Group Meeting date: 25 January 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Majid Ahadi Dolatsara * Ming Yan Radek Biernacki * Rui Yang Todd Bermensolo Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to Submit the Alphanumeric Pins BIRD draft to the Open Forum. - Done. - Arpad to Submit the Clocked Rx AMI Models BIRD draft to the Open Forum. - Done. - Michael Mirmak to send his AMI [Test Data] presentation to the ATM list. - Done. - Fangyi to review Walter's draft of BIRD 211.4. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 18th meeting. Michael moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: Arpad's new Repeater_Type Value question email: Arpad noted that he had recently come across an AMI model that contained a Model Specific parameter that allowed the user to switch the mode of operation between redriver and retimer. However, the model also included the Repeater_Type Reserved Parameter, which contained the value "Redriver". Arpad said this could be problematic, since the tool should do different things depending on whether the model is a Redriver or a Retimer. Arpad asked why the Repeater_Type was defined as having only a single value. Why do we not allow the Repeater_Type to have Format List and allow Redriver or Retimer to be selected? Should we make this possible? Is there a reason for not allowing it? Walter had replied to the email stating that he thought they would be two fundamentally different models. The model maker should use a [Model Selector] and two separate [Model]s. He didn't think we needed to complicate EDA tools to deal with this scenario, and he noted that an .ami file supporting both would likely have some parameters that only applied to the Redriver and others that only applied to Retimer, and this would be confusing. Arpad said a [Model Selector] approach forced the model maker to duplicate the entire [Model] just to provide a different [Algorithmic Model] section. Ambrish said he saw no harm in allowing the List. He said AMI models are just software and the parameter could select the mode. Michael asked if the device could change modes on the fly. He said that things that are hard to do in hardware are usually similarly hard to do in modeling. He said it's hard to create something that can be a redriver or retimer and switch between them. Changing the Repeater_Type parameter to allow a List for selection would imply that this is something the user could do on a whim. Fangyi agreed with Walter and Michael that it was unlikely that hardware could switch modes in real time. He agreed with Walter that a combined AMI file with DFE and CTLE parameters, each of which applied to only one of the modes, would make the model operation complicated and confusing. For example, if the user wanted to sweep the Redriver CTLE settings, they would also see DFE and other Retimer-only settings. Randy agreed that, as a model user, he would want entirely separate .ami files. He said it would be very confusing to have both combined into one .ami file. Arpad asked if Dependent (Dep) parameters could be used to clarify the situation. Fangyi said no. Michael asked whether the concept of an "AMI Selector" would help, if Arpad was concerned about duplicating the entire [Model] to use the [Model Selector] approach. Arpad asked whether anyone else in the group thought we needed to do anything to change the Repeater_Type parameter definition. No one responded. No change is planned at this time. Power Supply Induced Jitter (PSIJ) Modeling in IBIS: Randy reported that his discussions with the MS&T team have continued. He said he had been reviewing some NGSPICE code and looking at their algorithms. He will be doing more testing. GDDR6X: Walter said they had implemented support for GDDR7, which he believed was the JEDEC equivalent of the Micron/NVIDIA GDDR6X. He said he didn't think we needed anything new in terms of a BIRD. It's just single-ended PAM4. As soon as you go differential at the front end, everything looks the same in the .dll. He said the threshold parameters are relative to the differential waveform. It's not really different than single-ended NRZ AMI modeling. Fangyi said the existing DC_Offset parameter definition would apply. Randy noted that a presentation from Fangyi at the most recent IBIS summit had talked about non-linearities that can add complexities. It does have its challenges, and perhaps improvements in EDA tools, etc., could be applied. Walter said there are some non-linearities you may want to include, but they can be handled by Model Specific parameters. He said the AMI specification for the input waveform to the Tx is fine. There may be some non-linearities in the output levels, but these can be handled in the model. There are also some rise- time subtleties in the difference between 0-1, 0-2, or 0-3 transitions, for example. These edge rate differences might be measurable with a 50 Ohm termination, but as soon as you put them through a real lossy channel any edge timing differences are filtered out. AMI root name clarification BIRD: Michael discussed the BIRD draft he had sent out. He said it is a clarification BIRD that unambiguously states the relationship between the top-level tree name in the .ami file and the first string value in the AMI_parameters_in and AMI_parameters_out contents. He said that the interpretation of the IBIS 7.1 specification by most EDA tools is that the first value in AMI_parameters_out must exactly match the root name in the .ami file. Some models didn't follow this rule, and EDA tools sometimes emit confusing error messages. He noted that he had filed ibischk parser BUG227 for this issue, and it had been deferred until this BIRD is addressed. Michael noted that Mike LaBonte had provided some suggestions that had not yet been incorporated. He said there might be an updated draft coming. Bob asked if there were parser implications. Michael said his interpretation was that the parser could call the executable model functions and issue a warning if there is a mismatch between what the model returns and the .ami file root name. He acknowledged that this would be a non-trivial upgrade to the parser, as it does not currently call any of the executable model functions. He said this was also part of the justification for him proposing that the [Test Data] data keyword be expanded to include AMI support. Agenda email cleanup: Arpad suggested that Item 9 could be removed. He said he would move Michael's AMI root name checking BIRD to its own item. The other entry in item 9, Update outstanding BIRDs with new IBIS 7.1 page numbers, had already been completed and could be removed. There were no objections to this suggestion. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 01 February 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives